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REMARKS 

This amendment responds to the Office Action mailed on July 24, 2008, the statutorily 
shortened period of which expires on October 24, 2008. Applicants respectfully submit that this 
response is being filed within three (3) months of the mailing of the Office Action. 

The Specification has been amended to correct obvious typographical errors. 
Accordingly, no new matter has been entered. 

Claims 19, 20 and 22-24 are pending and have been rejected. Applicants traverse these 
rejections and respectfully request reconsideration and allowance of all the pending claims based 
on the following remarks. 

Claim Rejections - 35 U.S.G § 103 

I. 35 U.S.C. 103(a) Rejection of Claims 19-20 & 22-24: Naylor & IBM 

Claims 19-20 and 22-24 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Naylor et al. US Patent 6,625,642 in view of an IBM Corporation product Facsimile Support/400 
hereinafter known as IBM. (Pg. 3, Office Action). This rejection is respectfully traversed. 

Independent Claim 19 recites, in pertinent part: 

19. An electronic business transaction service 
method for conducting a business transaction over a 
computer network, comprising: 

receiving from a client computer an electronic 
business transaction document that is compatible with 
a business management software program ... the 
electronic business transaction document including 
address information and a preferred communication 
format indicator for each of the plurality of recipient 
parties of the business transaction, the address 
information and the preferred communication format 
being automatically retrieved from an electronic 
address book stored at the client computer ... 

(emphasis added). 
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A. Naylor 

Naylor In view of IBM fails to teach, suggest or disclose a "preferred communication 
format indicator beinu automatically retrieved from an electronic address book stored at the 
client computer" as recited by Claim 1.9. 

Rather, Naylor actually teaches away from a "preferred communication format indicator 
being automatically retrieved from an electronic address book stored at the client computer" of 
Claim 19, as Naylor specifically teaches: 

As shown in FIG. 3, a user wishing to transmit 
a document to the server to have it forwarded via fax 
or email, would place the document in the fax device 
scanner (step 300) and enter one or multiple 
destination identifiers into the fax device keyboard 
(step 302V The destination identifier(s) would either 
take the form of a phone number, or an email address, 
or both, depending on where and how the sender 
wishes the document to go. The email addresses or 
fax numbers could also have been entered beforehand 
and stored in a memory location in the memory of the 
fax device. In such a case the user would select the 
memory location via a method appropriate to the fax 
device in order to designate the email addresses or fax 
numbers contained therein. 

(Naylor, Col. 9:57 to Col. 10:3) (emphasis added). 

Therefore, as shown from above, a user must manually " enter one or multiple destination 
identifiers into the fax device keyboard" or the user must manually " select the memory location 
via a method appropriate to the fax device in order to designate the email addresses or fax 
numbers contained therein". This is the exact opposite of having a "preferred communication 
format indicator being automatically retrieved from an electronic address book stored at the 
client computer" as recited by Claim 19. 
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Naylor further teaches: 

Alternatively, the server may contain one or . 
more memory locations containing listings of email 
addresses or fax telephone numbers, such as for 
example in the form of a mailing list. In such a case, 
the sending: fax device can elect to send emails or 
faxes to recipients stored in such a server repository. 
This would be accomplished by providing an 
indicator in the fax transmission which designates the 
appropriate memory location for the desired listing 
resident in the server, rather than or in addition to the 
aforementioned email addresses or fax numbers . 

(Naylor, Col. 10:3-13) (emphasis added). 

Again, this portion of Naylor shows that the user must manually provide "an indicator in 
the fax transmission 11 rather than, or in addition to, manually providing the "aforementioned 
email addresses or fax numbers" shown above (Naylor, Col. 9:57 - Col. 10:3) to use listings of 
email addresses or fax telephone numbers. This clearly teaches away from a '"preferred 
communication format indicator being automatically retrieved from an electronic address book " 
as recited by Claim 19. 

B. IBM 



Independent Claim 19 recites, in pertinent part: 

19. An electronic business transaction service 
method for conducting a business transaction over a 
computer network, comprising: 

receiving from a client computer an electronic 
business transaction document ... including a [1] 
preferred communication format indicator for each of 
the plurality of recipient parties of the business 
transaction , the address information and the preferred 
communication format |2| being automatically 
retrieved from [3] an electronic address book stored at 
the client computer ... 

(emphasis added). 



8 

LA 127,189.520*1 070325-O4OO17 



Application No. 09/849.513 



PATENT 
Docket No. 070325-040017 



1, "preferred communication format indicator for each ... recipient" 

First, IBM fails to teach, suggest or disclose " a preferred communication formal indicator 
for each of the plurality of recipient parties of the business transaction " as recited by Claim 19. 
The Examiner admits on Page 7, Second Paragraph of the Office Action that: ; iBM does not 
explicitly teach preferred communication format indicator for each of the plurality of recipient 
parties of the business transaction. " IBM teaches that all communications must occur according 
to the ;; CC1TT Group 3" (ax format (IBM, Pg. 2) and that the "Facsimile Support/400 product 
send process" must ik [c]onvert the cover page and spooled file [the rest of the pages] to the 
Group 3 fax format" (IBM, Pg. 4-5). Therefore, since all communications sent to recipients by 
the IBM device occur according to the "industry standard" "CCITT Group 3" fax format (IBM, 
Pg. 2), IBM actually teaches away from multiple, different "preferred communication formats" 
for each "of the plurality of recipient parties of the business transaction" as recited by Claim 19. 

2. "preferred communication format indicator being automatically retrieved" 

Second, the Examiner states on Page 2 of the Office Action that "In IBM, [a] computer 
that generates documents can embed [the] address of one or more recipient(s). I BM teaches [the] 
capability to send a fax to a previously defined destination or a fax distribution list [IBM, page 
4]/* Applicants respectfully submit that the Examiner is mistaken as to his interpretation of IBM. 

IBM still foils to teach, suggest or disclose a "preferred communication format indicator 
being automatically retrieved from an electronic address book stored at the client computer" as 
recited by Claim 19. As a matter of fact, IBM teaches away from this above recited limitation of 
Claim 19. As can be seen on Pages 105- II 1 of IBM ("Using the Submit Fax Window"), a user 
must manually enter telephone number data and recipient data . into the various fields. Therefore, 
IBM necessarily fails to teach, suggest or disclose any feature that enables a "preferred 
communication format indicator [to be] automatically retrieved from an electronic address book 
stored at the client computer" as recited by Claim 1 9. 
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3. "electronic address book" 

Third, the "SBMFAX command 1 ' (Submit Fax command) disclosed on Pg. 4 of IBM and 
pointed out by the Examiner, as well as the rest of IBM, fail to teach, suggest or disclose an 
" electronic address book " or any equivalent structure, as recited by Claim 19. As disclosed by 
Applicants' Specification, the "electronic address book" may 'include conventional information 
about each party 10 : such as name, business name, address, telephone number, facsimile number, 
email address, etc." (Applicants' Spec, Pg. 7, lines 26-28). Therefore, unlike IBM, which is 
merely able to u |s]end a fax to a previously defined destination or fax distribution list" (IBM, Pg. 
4), the claimed " electronic address book " stores not only facsimile and telephone numbers, but 
also email addresses, and physical addresses for sending communications through conventional 
(i.e.. paper) .mail. (E.g; Applicants 5 Spec, Pg, 1, line 28 to Pg. 12 ? line 3). Furthermore, the 
Applicants' Specification discloses that the claimed " electronic address book " can be represented 
by "an address book data structure 60 that includes conventional address book information fields 
62 and a business transaction document communication format field 64 " (Applicants'' Spec, Pg. 
7, lines 32-34). IBM lacks the sophistication of "data structures 55 with such "Fields, 2 ' and in its 
entirety fails to disclose any equivalent features or structures. Therefore, it is clear that IBM fails 
to teach, suggest or disclose an " electronic address book " of Claim 1 9. 

Therefore, Applicants respectfully request the withdrawal of this 35 U.S.C. 103(a) 
rejection, because Claim 19, and dependent Claims 20 and 22-24 are allowable over Naylor in 
view of IBM. 

II. 35 U.S.C. 103(a) Rejection of Claims 19-20 & 22-24: IBM, Henry & Akimoto 

"Claims 19-20 and 22-24 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
an IBM Corporation product Facsimile Support/400 hereinafter known as IBM in view of Henry 
US Patent 6,424,426 and Akimoto US Patent 6.775,71 1 (Pg. 6, Office Action). This rejection is 
re-spec till I I'y traversed. 
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A. IBM 



For at least the reasons provided above, IBM fails to teach, suggest or disclose all of the 
limitations of Claim 19. 

B. Henry 

Independent Cjaim 19 recites, in pertinent part: 

19. An electronic business transaction service 
method for conducting a business transaction over a 
computer network, comprising: 

receiving from a client computer an electronic 
business transaction document ... the electronic 
business transaction document including address 
information and a [ 1 ] preferred communication format 
indicator for each of the plurality of recipient parties 
of the business transaction , the address information 
and the [2] preferred communication format being 
automatically retrieved from an electronic address 
book stored at the client computer, wherein the 
electronic business transaction document is [3j 
received by a transaction service server computer 
communicating with the client computer through a 
computer network : ... 

(emphasis. added). 

1. "preferred communication format indicator for each ... recipient" 

First, Henry fails to teach, suggest or disclose " a preferred communication format 
indicator for each of the plurality of recipient parties of the business transaction " and 
" determining at the transaction service server computer a preferred communication format for 
each of the plurality of recipient parties of the business transaction " as recited by Claim 19. The 
Examiner admits on Page 8, Second Paragraph of the Office Action that: "IBM in view of Henry 
does not explicitly teach determining at the transaction service server computer a preferred 
communication format for each of the plurality of recipient parties of the business transaction." 
Therefore. Henry fails to teach, suggest or disclose the above recited limitations of Claim 19. 
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2. "preferred communication format indicator being automatically retrieved" 

Second, Henry fails to teach, suggest or disclose a " preferred communication format 
indicator beinu automatically retrieved from an electronic address book *" as recited by Claim 19. 
Henry is directed to a system where users manually fill out a form with email addresses and scan 
such a form into a fax machine, so that it is faxed to a fax server. (See Henry, Abstract and FIG. 
3B, 4 and 8 A). However, Henry fails to make any mention of a preferred communication format 
indicator "being automatically retrieved " because in Henry as user must manually 'Till in the 
letterboxes, in normal handwriting, with the final email address(es) it wishes to send to" (Henry, 
Col. 5:7-10). Also, Henry fails to teach, suggest or disclose an " electronic address book " of 
Claim 19 because there is no electronic address book "data structure" or equivalent structure that 
is disclosed by Henry (See Applicants' Spec, Pg, 7, lines 32-34), thus, Henry clearly fails to 
teach, suggest or disclose a " preferred communication format indicator beinu automatically 
retrieved from an electronic address book " as recited by Claim 19, 

3. "communicating with the client computer through a computer network" 

Third, Henry fails to teach, suggest or disclose "wherein the electronic business 
transaction document is received by a transaction service server computer communicating with 
the client computer through a computer network " as recited by Claim 1 9. 

Henry is cited by the Examiner in on Page 7, Second Paragraph of the Office Action as: 
"Henry teaches {an] idea wherein a business document can be sent b[y] a server to a recipient 
party in their preferred format (fax-to-email and email-to-fax formats).' 1 However, Henry does 
teach, suggest or disclose "wherein the electronic business transaction document is received by a 
transaction service server computer communication with the client computer through a computer 
network " of Claim 19. Rather, Henry discloses technology related to the. Internet fax service 
MongoNet (See Henry, FIG. 4, FIG. 6, and http:/Avwv.mongQnet.com ) where users manually 
fill out a form with email addresses (Henry, Col. 5:3-15) and scan such a form into a fax machine 
so that it is faxed to a fax server (Henry, Col. 17-26). 
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In other words, the document in Henry is created by a user that manually fills in the email 
address on the form, not " automatically retrieved " by a computer program, recited by Claim 19. 
Most importantly, the document in Henry is sent via facsimile to a fax server (Henry, Col. 16-19, 
FIG. 2 ; FIG. 8A), not over t; a computer network " in electronic form to a server. Thus, it is 
respectfully submitted that Henry fails to teach, suggest or disclose "wherein the electronic 
business transaction document is received by a transaction service server computer 
communicating with the client computer through a computer network s as recited by Claim 19. 

C. Akimoto 

Independent Claim 1 9 recites, in pertinent part: 

19. An electronic business transaction service 
method for conducting a business transaction over a 
computer network, comprising: 

receiving from a client computer an electronic . 
business transaction document the electronic 
business transaction document including address 
information and a [1] preferred communication format 
indicator for each of the plurality of recipient parties 
of the business transaction , the address information 
and the [2] preferred communication format beinu 
automatically retrieved from an electronic address 
book stored at the client computer, wherein the 
electronic business transaction document is received 
by a transaction service server computer 
communicating with the client computer through a 
computer network; ... 

(emphasis added). 

1. "preferred communication format indicator for each ... recipient** 

First, Akimoto fails to teach, suggest or disclose " a preferred communication format 
indicator for each of the plurality of recipient parties of the business transaction " and 
" determining -at the transaction service server computer s preferred communication format for 
each of the plurality of recipient parties of the business transaction 9 ' as recited by Claim 19. 
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The Examiner cites Akimoto on Page 8, Second Paragraph of the Office Action as 
supposedly disclosing these above limitations of Claim 19 ("Akimoto, Fig. 8 and disclosure 
associated with Fig. 8"). However, Applicants respectfully submit that the Examiner is mistaken 
as to his interpretation of Akimoto. Akimoto still fails to teach, suggest or disclose "determining 
at the transaction service server computer a preferred communication format for each of the 
plurality of recipient parties of the business transaction " where the communication format 
received by the recipient party can be a "computer communication format" or a "non-computer 
communication format". To the contrary. Akimoto isidirected to an email communication system 
having only a single communication formal: namely, all communications occur according to a 
standard "MIME" based "e-mail transfer protocol." (See Akimoto, Col. 5: 19-54, Col.9:47). There 
is no teaching or suggestion in Akimoto that communications or trasmissions to recipients can 
occur in any format other than the standard "e-mail transfer protocol" format. 

On Page 8, Second Paragraph of the Office Action, the Examiner cites "Akimoto. Fig. 8 
and [the] disclosure associated with Fig. 8" in an effort to anticipate the " determining at the 
transaction service server computer a preferred communication format for each of the plurality of 
recipient parties of the business transaction ." However, rather than describe the "preferred 
< commmunication formats" (e.g. "computer communication format" or "non-computer 
communication format") of recipient parties, Fig. 8 and the disclosure of Akimoto pertaining to 
Fig. 8 only discuss how various identification characters can be used to signify that certain 
processes be performed on an email that is being sent, which is not related to the " preferred 
communication format " as claimed. (See, e.g. Akimoto, Cols. 7-9). For example, Akimoto 
"detects the characters ; A' to 4 C ? after the identification character ( @' [in an email address]" to 
determine that "processing according with these characters is exected." (Akimoto, Col. 8:31-35). 
"When the identification 5 A ! is added, signature processing is carried out. When the 
identification 4 B ? is added, encryption processing is carried out. When the identification 'C ? is 
added, JPEG conversion is carried out. The JPEG conversion is herein referred to processing for 
converting the MH file to the JPEG file." (Akimoto, Col. 7:30-35) (describing FIG. 7). 
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However, as clearly shown at the bottom of the flow chart illustrated in FIG. 8, regardless 
of which type of content processing has been indicated to be performed, all communications are 
ultimately transmitted (in the 'Transmission Processing" step) in an "e-mail transfer protocol" 
(Akimoto, Col. 9:47) format where determinations are made (in steps IT 3 and T14) to ensure 
that the recipient address is in a "suitable format" for email. (Akimoto, Col. 8:60-65), Therefore, 
instead of disclosing "delerming different communication formats " as recited by Claim 19, 
Akimoto merely discusses how various identification characters are used to process the content 
of an email (e.g. signature or encryption processing) before the content is transmitted according 
to an "e-mail transfer protocol" format (Akimoto, Col. 9:47). regardless of the type of content 
processing that was performed according to the identification characters. For example, Akimoto 
teaches that if "it is determined that the specific character is included therein, the server executes 
processing, which is made to correspond to the identification character, with respect to image 
data stored in the memory. Thereafter the server transmits processed image data to the sender in 
accordance with an e-mail transfer protocol ." (Akimoto, Col. 8:42-47) (emphasis added). As 
such, Akimoto only discloses only one, single computer communication format ("e-mail transfer 
protocol") that is used for all recipient parties, unlike the multiple and different " communication 
formats for each of the plurality of recipient parties" as recited by Claim 19. 

Therefore, because Akimoto only discloses using one, single and unchaged computer 
communication format ("e-mail transfer protocol"), Akimoto clearly fails to teach, suggest or 
disclose "determining at the transaction service server computer a preferred communication 
format for each of the plurality of recipient parties" where the preferred communication format 
can be a "computer communication format" (e.g. email) or a "non-computer communication 
format" (e.g. fax). In addition, the fact that Akimoto uses a single "e-mail transfer protocol" 
computer communications format for all its communications is similar to the fact that IBM uses 
a single "CC1TT Group 3" (fax) non-computer communications format for all its 
communications (IBM, Pg. 4-5). As Applicants' Specification discloses, the "expense, time and 
cooperation required to implement for such an indislry-wide standard can be significant" 
(Applicants' Spec, Pg. 2, lines 3-5). Thus, the present application is advantageously designed to 
avoid the problem of a single, industry-wide standard practiced by both Akimoto and IBM. 

15 

LA 127,189.520v1 070325-040017 



Application No. 09/849,513 " PATENT 

Docket No. 070325-040017 

2. "preferred communication format indicator being automatically retrieved" 

Second, Akimoto fails to teach, suggest or disclose a " preferred communication format 
indicator being automatically retrieved from an electronic address book '' as recited by Claim 19. 
Akimoto is directed to an email communication system where all communications are sent 
according to one format ("e-mail transfer protocol")- Therefore, there is no teaching or 
suggestion in Akimoto of a " preferred communication format ". Furthermore, Akimoto fails to 
teach, suggest or disclose an "electronic address book" because there is no electronic address 
book "data structure" or equivalent structure disclosed by Akimoto (See Applicants' Spec, Pg. 
7, lines 32-34). Thus, Akimoto clearly fails to teach, suggest or disclose a " preferred 
communication format indicator being automatically retrieved from ah electronic address book " 
as recited by Claim 19. 

D. Claim 22 

On Page 9, Fourth Paragraph of the Office Action, the Examiner rejects Claim 22, stating 
that "IBM in view of Henry, Akimoto and NetGram teaches adding a recipient party to the 
electronic business transaction document automatically associates with the recipient party the 
preferred communication format indicator." Applicants respectfully submit that the Examiner is 
mistaken in listing "NetGram" in this rejection, because "NetGram" was not mentioned in the 
rejection shown on Page 6, Last Paragraph of the Office Action, and all the other rejections of 
Claims 19-20 and 22-24 only involve IBM, Henry or Akimoto. As set forth herein, the 
combination of IBM, Henry and Akimoto tails to teach, suggest or disclose "wherein adding a 
recipient party to the electronic business transaction document automatically associates with the 
recipient party the preferred communication format indicator " for at least the reasons of 
dependency on allowable Claim 19, and also because all the cited prior art fails to teach, suggest 
or disclose at least the " preferred communication format" limitation as recited by Claim 22, as 
proven above in the Remarks. 
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Therefore, Applicants respectfully request the withdrawal of this 35 U.S.C. 103(a) 
rejection, because Claim 19, and dependent Claims 20 and 22-24 are allowable over IBM in 
view of Henry and Akimoto. 



In each case,, the pending rejections should be reconsidered in view of the amendments 
and remarks herein. Applicants believe that this case is in good condition for allowance, and a 
Notice of Allowance is earnestly solicited. If a telephone or further personal conference would 
be helpful, the Examiner is invited to call the undersigned at 949-732-6572, who will cooperate 
in any appropriate manner. to advance prosecution. The Commissioner is directed and authorized 
to charge all required fees, except for the Issue Fee and the Publication Fee, to Deposit Account 
Number 50-2638. Please also credit any overpayments to said Deposit Account. Please ensure 
that Attorney Docket Number 070325-040017 is referred to when charging any payments or 
credits for this case. 
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CONCLUSION 



Respectfully submitted, 
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